Setting real time clocks in communications netwroks

ABSTRACT

A request requesting a real time clock (RTC) value in a communications network is sent from a network element to a management system via a data communications network. The time taken from the sending of the request to the receipt of the RTC value is compared with a predetermined maximum and, if less than or equal to the maximum, the network element RTC is updated. If above the maximum, the RTC value is discarded, and a fresh request is sent. The received acceptable RTC value may be corrected by subtracting either the minimum transmission time or half the actual transmission time.

This invention relates to communications networks, and in particular tothe setting of real time clocks in such networks.

Many networks include a management layer that is used to control andconfigure elements within the network. An example of such a network isthe Synchronous Digital Hierarchy (SDH) transmission network. FIG. 1shows a typical situation within such a network. A management system 10and network elements 12, 14 communicate with each other over a datacommunications network (DCN) 16. The management system carries out anumber of functions including configuration, collection of performancemetrics and collection of alarm states. In order to enable robustcommunications, and allow for correct routing of data, standardprotocols such as OSI (open systems interconnect) and TCP/IP(transmission control protocol/internet protocol) are used across thenetwork. The network which carries the management layer may becompletely independent of the network elements, referred to as out ofband, or carried within the traffic that they process, referred to as inband. In the example of SDH, this is typically carried in the datacommunications channel (DCC) within the traffic section overhead (SOH)as defined in the SDH standards.

Where the management system is collecting performance and alarm statedata it is important to know either over what time period the data wascollected and/or the precise time a given event occurred. This isparticularly important when verifying the quality of service deliveredto customers and when fault finding in the network.

In the case of alarms, it is important to correlate accurately alarms toassist in fault finding to establish quickly any traffic loss impact tospecific customers.

Management systems typically have a Global Positioning System (GPS) link18 (FIG. 1) to provide a highly accurate time reference. This enablesthe time, as a real time clock, to be set within the network elements sothat the time that performance data or alarms were collected over can bespecified accurately. Once obtained from the GPS, the management systemdistributes the time over the DCN to all the network elements. Dependingon the running accuracy of the real time clock (RTC) within the networkelement, the management system can update the network element RTC atregular intervals which, typically, vary from hours to days asappropriate.

It is well understood in the art that there are problems associated withsetting the real time clock accurately within network elements. Theseproblems arise for three main reasons: transit delays over the datacommunications network; setting delay when the time is received at agiven network element; and data communications network protocolre-transmissions.

The first of these, transit delays, are due to the routing of themessages over the DCN. In a large network, messages may travel over anumber of elements each of which stores, processes and forwards themessage. The transit delay is typically small, being in the order of 5ms. As the transit delay is fairly stable and predictable it can becompensated for by simple subtraction.

The setting delay only applies at the receiving network element and isthe time taken for the termination of the received message and thesetting of the internal RTC. As with the transit delay this iscontrollable and can be reduced to a few hundred ms by giving the RTCsetting a high software priority.

The most problematic source of delay is in DCN protocolre-transmissions. The DCN network is robust and caters for messagetransmission failures. The protocols used, typically in the transportlayer, allow for the detection of failure and the re-transmission ofmessages. Since failures are likely to be caused by a temporary overloadin the DCN network, the retransmission protocols have a back-offmechanism in which there is a waiting time before re-transmission. Thismay be appreciated from a consideration of FIG. 2 which is a schematictiming diagram showing the sequence of events from the managementsystem, data communications network and network element. A message 20 issent by the management system to the network element via the DCN. Thefirst three attempts by the DCN to send the message received from themanagement system on to the network element fail and the message is onlysent on the fourth attempt. The delay between successive attemptsincreases to increase the chances of success. Thus, the delay betweenthe first and second attempts is four seconds; between the second andthird attempts is eight seconds; and between the third and fourthattempts is 16 seconds giving rise to a total delay of 28 seconds.

The most significant problem arising from this delay is that neither themanagement system nor the network element has knowledge of it asre-transmission is handled by protocols within the DCN. Moreover, themessage re-transmitted by the DCN protocol is always the same message assupplied by the management system. Thus, in the example given, the timevalue received at the network element will be 28 seconds slow withrespect to real time.

As a result of this delay accumulation, network elements in a largenetwork can vary in time value by a large range. This may be up to 64seconds depending on the re-transmission times set for the DCNprotocols.

Many attempts have been made to solve the above discussed problem.However, none of the solutions proposed are satisfactory. The existingattempts at solving the problem rely on a constant requesting andcomparing of times across the network by the management or main controlsystem. Differences are calculated and adjustments made to times sent asrequired. Such an approach works well on a reasonably controllednetwork, but reliability is reduced over large networks, wherere-transmission may occur often. They are also complex to run on largenetworks.

Other solutions proposed rely on sending out some form of RTC indicationwith the traffic carried by the network elements. This propagates overthe network quickly allowing for accurate RTC settings. However, such anapproach uses up valuable traffic bandwidth and requires a complexinterconnection of traffic to ensure that all network elements within anetwork receive it.

The invention aims, therefore, to provide an improved approach tosetting real time clocks which overcomes or ameliorates thedisadvantages mentioned above.

In its broadest form, the invention overcomes, at least in part, theabove mentioned problems by sending RTC request messages from thenetwork element to the RTC source. This enables the time for the roundtrip to be monitored. If it is not within a predefined range, the RTCvalue received is rejected and a fresh request made.

More specifically, there is provided a method of setting a real timeclock in a network element of a data communications network having amanagement system communicating with the network element across thenetwork, the method characterised by: sending a message from the networkelement to the management system requesting a real time clock (RTC)value; receiving the RTC value at the network element; measuring thetime taken between the sending of the RTC request message and receipt ofthe RTC value; comparing the measured time with a predeterminedacceptable time; and if the measured value is acceptable: setting thenetwork element real time clock with the received value.

The invention also provides a network element for a data communicationsnetwork having a management system communicating with the networkelement across the network, the network element comprising: a real timeclock; a message generator for generating and sending real time clock(RTC) value requests to the management system; a message receiver forreceiving requested RTC values from the management system; a timer formeasuring the time between sending of an RTC request message and receiptof the RTC value; a comparator for comparing the measured time with apredetermined acceptable time; and means for setting the network elementreal time clock with the received RTC value if that value is acceptable.

The invention further provides a data communications system comprising:at least one network element and a management system, the networkelement and the management system communicating across thecommunications network; characterised in that the system comprising atthe network element: a real time clock set by the management system; amessage generator for generating and sending real time clock (RTC) valuerequests to the management system; a message receiver for receivingrequested RTC values from the management system; a timer for measuringthe time between sending of an RTC request message and receipt of theRTC value; a comparator for comparing the measured time with apredetermined acceptable time; and means for setting the network elementreal time clock with the received value if that value is acceptable; andat the management system: means for receiving RTC value request messagesfrom the network element and for sending RTC values to the networkelement in response thereto.

The invention still further provides a method of setting a real timeclock in a network element of a data communications network comprising:requesting a real time clock value RTC from a remote RTC source;measuring the period between the RTC request and receipt of an RTCvalue; and updating the real time clock of the network value if themeasured period is within a predetermined acceptable range.

Embodiments of the invention have the advantage that by departing fromthe prior art arrangement of the management system sending out requestswithout the knowledge of the network element, the time taken to receivethe RTC value can be measured. If it is too high, the RTC value can bediscarded.

Preferably, if the number of discarded RTC values exceeds apredetermined number, an alarm is sent to the management system. Thishas the advantage of alerting the management system to a persistentfault or problem.

Preferably, the acceptable RTC values are modified to take into accountthe transmission time from the management system. In one preferredembodiment this is achieved by subtracting the minimum transmission timeand in another preferred embodiment by subtracting half the measuredtransmission time. This has the advantage that the real time clock setat the network element is more accurate.

Embodiments of the invention will now be described, by way of exampleonly, and with reference to the accompanying drawings, in which:

FIG. 1, discussed earlier, is a schematic view of a typical networkconfiguration;

FIG. 2, discussed earlier, shows how a message sent from the managementsystem to a network element can accumulate a substantial delay;

FIG. 3 illustrates the principle of the present invention in terms ofmessage flow between management system and network element;

FIG. 4 shows how the FIG. 3 example works with message re-transmissionfrom network element to management system;

FIG. 5 is a similar view to FIG. 4 but with message re-transmission frommanagement system to network element;

FIG. 6 is a flow chart showing the steps occurring at the networkelement;

FIG. 7 is a flow chart showing a first method of correcting the receivedRTC; and

FIG. 8 is a flow chart showing a second method of correcting thereceived RTC.

The inventors have appreciated that the problems in the prior artsystems discussed above arise because the management system and networkelement have no knowledge of the re-transmission within the DCN network.This is because messages are sent to the network element over the DCNand a reply awaited. This ensures reliable transmission but delaysoccurring within the DCN are undetectable.

In the embodiment to be described, the process is reversed. Rather thansending RTC settings from the management system at some predeterminedtime, the RTC is sent in response to a specific request from the networkelement. The network element can time the period between the issue ofthe response and the receipt of the RTC and determine the validity ofthe RTC value by comparing the measured period with the accuracyrequired within the network element.

The control of the sequence is thus within the network element, whichcan control and monitor the entire process. As an additional benefit,processing issues related to the extra work involved are distributedacross the network rather than handled by one process such as in themanagement system.

The network element requests the RTC value from the management systemand times the period until receipt. This is a relative time and is notrelated to any inherent accuracy of the current RTC setting, but onlythe timing of a given period of time. Thus, the validity of the RTC timevalue can be determined. If the time taken for the response exceeds amaximum acceptable, the network element sends another request after aback off period to allow the DCN to clear.

FIG. 3 shows how this works for a successful request with nore-transmission. It may be assumed, for the purposes of explanation,that the acceptable accuracy of the RTC is to within 5 seconds. That is,the time taken between the network element issuing an RTC request to themanagement system and the receipt of that RTC by the network elementmust not exceed 5 seconds.

Each of the propagation legs will have a predictable delay. It may beassumed that the transit time between the network element and themanagement system is 300 ms in both directions and that the managementsystem has a response time of 500 ms.

Thus, in FIG. 3 at 30 the network element starts a timer and sends anRTC request to the management system across the data communicationsnetwork. The first attempt to send the message succeeds as does theresponse from the management system to the network element. The timer isstopped when the RTC is received at the network element at 32. In thiscase the measured time will be 300 ms+500 ms+300 ms=1.1 seconds. This iswithin the acceptable accuracy of 5 seconds and so the network elementwill accept it.

In FIGS. 4 and 5, the sequences are shown where there arere-transmissions. In FIG. 4, the re-transmission is from the networkelement to the management system. In the example shown the first attemptfails and the second attempt, 4 seconds later, succeeds. The total timefor the RTC to reach the management system is (300×2 ms)+400 ms=4600 ms(4.6 seconds). The return path from the management system is successfulat the first attempt so that the total time between starting andstopping the timer is 4600 ms+500 ms management response time+300 msmanagement system to network element propagation time. This gives atotal of 5.4 seconds. This time is unacceptable and the network elementwill therefore reject the RTC value and send a new request.

It will be appreciated that in the FIG. 4 example the RTC received isaccurate as there is no delay between the management system and thenetwork element beyond the normal 300 ms delay. However, the networkelement can only measure the total time for the round trip and cannotdetermine where the delay has occurred. The network element musttherefore reject the received RTC value.

FIG. 5 differs from FIG. 4 only in that the RTC request sent from thenetwork element to the management system is successful at the firstattempt but the RTC message sent back to the network element issuccessful only at the second attempt, inserting a 4 second additionaldelay. The total time recorded by the network element timer is again 5.4seconds and the RTC value must be rejected. In this example it will beappreciated that the RTC value actually is inaccurate as the substantialdelay has occurred after it was sent by the management system.

Where a received RTC is rejected, the network element continues to useits existing RTC until an RTC request is answered within the acceptabletime period.

After the network element has rejected a predetermined number ofconsecutive RTC values, a time-out will occur and the network elementwill raise an alarm to the management system to allow intervention bythe management system.

FIG. 6 is a flow chart showing the steps in the process at the networkelement. At step 100 the network element sends out the RTC value to themanagement system and starts the timer. At step 102 the network elementrecords the RTC value and stops the timer. At step 104 the networkelement compares the elapsed time. If it is within or equal to thepredetermined maximum, the network element resets its RTC at 106. If theelapsed time is greater than the predetermined maximum, the systemrejects the RTC value at 108 and the process loops back to the beginningwith a fresh RTC request being sent. Following rejection of the RTC, arejection counter is incremented at 110 and at 112 the value of thecounter is compared with a predetermined number. If the counter value isequal to that number an alarm is sent to the management system at 114.

The network element knows the time taken to receive the RTC message fromthe management system. This knowledge can be used to correct the realtime clock.

A first method is to define the minimum response time achievable. In theexample given above, this is likely to be about 1 second. The networkelement then adds 1 second to the received time to compensate for thetime taken to receive the message.

A second method bases the correction on the period of time taken for themessage to be received. The network element adds half the total timetaken to receive the response to reduce any error caused by transmissionthrough the network. If the delay occurs on the return leg, the FIG. 5example, but the total time is within the acceptable maximum, the errorcould be increased slightly but still within the acceptable limit.

These two alternatives are illustrated in the flow diagrams of FIGS. 7and 8 which expand the reset network element step 106 of FIG. 6. In FIG.7, the acceptable RTC is received at step 200. At 210 the minimumresponse time is subtracted and at 212 the network element RTC isupdated. In FIG. 8 the acceptable RTC is received at 300. At 302 thetime counter is halved and at 304 substracted from the received RTC. At306 the new value is used to update the RTC.

Many variations and modifications to the embodiments described arepossible and will occur to those in the art without departing from thescope of the invention which is defined by the claims appended hereto.

1. A method of setting a real time clock in a network element of a datacommunications network having a management system communicating with thenetwork element across the network, the method characterised by: sendinga message from the network element to the management system requesting areal time clock (RTC) value; receiving the RTC value at the networkelement; measuring the time taken between the sending of the RTC requestmessage and receipt of the RTC value; comparing the measured time with apredetermined acceptable time; and if the measured value is acceptable:setting the network element real time clock with the received value. 2.A method according to claim 1, wherein if the comparison of the measuredvalue and the acceptable value shows the measured value to beunacceptable, the received RTC value is rejected and a further RTC valuerequest message is sent by the network to the management system.
 3. Amethod according to claim 2, wherein upon determination that a receivedRTC value is unacceptable, the network element compares the number ofunacceptable values received with a maximum permissible number and, ifthe number of unacceptable values received equals the maximumpermissible number, sends an alarm to the management system.
 4. A methodaccording to any preceding claim, wherein the step of setting thenetwork element real time clock with an acceptable received valuecomprises correcting the received value to compensate for transmissiontime.
 5. A method according to claim 4, wherein the step of correctingthe received RTC value comprises subtracting a minimum transmission timefrom the received value.
 6. A method according to claim 4, wherein thestep of correcting the received RTC value comprises subtracting half themeasured time taken between sending of the RTC request message andreceipt of the RTC value.
 7. A network element for a data communicationsnetwork having a management system communicating with the networkelement across the network, the network element comprising: a real timeclock; a message generator for generating and sending real time clock(RTC) value requests to the management system; a message receiver forreceiving requested RTC values from the management system; a timer formeasuring the time between sending of an RTC request message and receiptof the RTC value; a comparator for comparing the measured time with apredetermined acceptable time; and means for setting the network elementreal time clock with the received RTC value if that value is acceptable.8. A data communications system comprising at least one network elementand a management system, the network element and the management systemcommunicating across the communications network; the system comprisingat the network element: a real time clock set by the management system;a message generator for generating and sending real time clock (RTC)value requests to the management system; a message receiver forreceiving requested RTC values from the management system; a timer formeasuring the time between sending of an RTC request message and receiptof the RTC value; a comparator for comparing the measured time with apredetermined acceptable time; and means for setting the network elementreal time clock with the received value if that value is acceptable; andat the management system: means for receiving RTC value request messagesfrom the network element and for sending RTC values to the networkelement in response thereto.
 9. A network element or data communicationssystem according to claim 7 or claim 8, and further comprising: meansfor rejecting the received RTC value if the measured time isunacceptable.
 10. A network element or data communications systemaccording to claim 9, wherein the network element comprises a furthercomparator for comparing the number of unacceptable received RTC valueswith a predetermined maximum, and an alarm generator for generating andsending an alarm to the management system if the predetermined maximumnumber of unacceptable values has been reached.
 11. A network element ordata communications system according to any of claims 7 to 10, whereinthe network element comprises a real time clock value corrector forcorrecting received acceptable real time clock values to compensate fortransmission time from the management system.
 12. A network element ordata communications system according to claim 11, wherein the real timeclock value corrector comprises a subtractor for subtracting from theacceptable RTC value the minimum time between sending the RTC valuerequest message and receiving the RTC value.
 13. A network element ordata communications system according to claim 11, wherein the real timeclock value corrector comprises a subtractor for subtracting half themeasured time taken between sending of the RTC request message andreceipt of the RTC value.
 14. A method of setting a real time clock in anetwork element of a data communications network comprising: requestinga real time clock value RTC from a remote RTC source; measuring theperiod between the RTC request and receipt of an RTC value; and updatingthe real time clock of the network value if the measured period iswithin a predetermined acceptable range.